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CROSS-REFERENCE TO RELATED APPLICATIONS 



[0001] 



The present application is a continuation of prior application No. 



08/987,346, filed on 12/09/97, entitled "Method and Architecture for Self-Provisioning 
a Rendezvous to Ensure Secure Access to Information In a Database from Multiple 
Devices," now U.S. Patent No. 6,065,120, which is hereby Incorporated herein by 
reference. 

COPYRIGHT STATEMENT 

[0002] A portion of the disclosure of this patent document contains material that 
are subject to copyright protection. The copyright owner has no objection to the 
facsimile reproduction by anyone of the patent document or the patent disclosure as 
it appears in the Patent and Trademark Office patent file or records, but othenwise 
reserves all copyrights whatsoever. 

BACKGROUND OF THE INVENTION 
Field of the invention 

[0003] The invention relates to user authentication systems over data network 
systems and, more particularly, relates to a method and system for self-provisioning, 
through a first device, a rendezvous to ensure secure access to managed 
information in a user account by other devices through the rendezvous In a data 
network, wherein the rendezvous is generally identified by a URL, the first device, 
coupled to the data network, runs a first browser under a first communication 
protocol and the other devices in the same data network run a second browser under 
a second communication protocol. 
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Description of the Related Art 

[0004] The Internet is a rapidly growing communication network of 
interconnected computers around the worid. Together, these millions of connected 
computers form a vast repository of hyperlinked information that is readily accessible 
by any of the connected computers from anywhere and anytime. To provide mobility 
and portability of the Internet, wireless computing devices were introduced and are 
capable of communicating, via wireless data networks, with the computers on the 
Internet. With the wireless data networks, people, as they travel or move about, are 
able to perform through the wireless computing devices exactly the same tasks they 
could do with computers on the Internet. 

[0005] The most common remote access paradigm is, as of today, the one in 
which a laptop personal computer is equipped with a wireless communication 
mechanism, for example, a wireless modem. This paradigm may remain useful for a 
considerable number of applications and users, but there has been a growing need 
for a mobile paradigm in which the Internet can be instantly accessed by mobile 
devices, such as cellular phones and personal digital assistants. The mobile devices 
are generally designed small in size and light in weight. With increasing data 
processing capabilities in the mobile devices, more and more users start carrying the 
devices around to materialize their unproductive time into productive time. As more 
commonly seen, regular mobile phones can return calls, check voice mail or make 
users thereof available for teleconferences anywhere and anytime, but desired 
mobile phones, not just reactive to calls but also proactive, can meld voice, data, and 
personal information with manager-like functionality into a single handset that can 
effectively, through a host computer, access a myriad of public and enterprise 
information services in the Intemet. 

[0006] The evolution of the mobile phones or the mobile devices has been 
fueled by the demand of users for immediate access to the information they are 
looking for. For example, a traveler may request an exact flight schedule when he is 
on his way to the airport, or a trader may purchase shares of stock at a certain price. 
The pertinent information from these transactions may include the airline and the 
flight number for the traveler, or the number and price of the shares being purchased 
by the trader To be timely informed, a preferable way is to communicate the 
information requests electronically into the wireless data networi^. The data network. 
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for example. cx»nnects to a flight information server or stocl^ quote server so that the 
desired flight information or the current stock price can be retrieved therefrom on 
demand. However, it becomes troublesome or impractical to key in lengthy 
infomnation queries electronically into the data network through a mobile device that 
typically has a keypad with a few buttons, much less functional compared to a 
keyboard in a personal computer system. There is, therefore, a great need for a 
method and system for efficiently communicating desired transactions into a data 
network through which the transactions can be performed or pertinent information 
can be retrieved, without the need to key in such information every time the 
transactions or the information is desired. In many cases, the desired information in 
a user account, especially regarding personal matters, is preferred to be confidential. 
Thus, there is further a need for a generic solution that provides a method and 
means for self-provisioning an account entry to a user account that has the 
proprietary information therein accessible only through the account entry. 

SUMMARY OF THE INVENTION 

[0007] The invention pertains to improved approaches for accessing data on a 
data network by a mobile device or a computing device. Typically, the mobile device 
(e.g., mobile telephone with a network browser) has a limited functionality user 
interface as compared with the full functionality user interface of the computing 
device (e.g., personal computer). 

[0008] The invention can be implemented in numerous ways, including as a 
method, system, apparatus, and computer readable medium. Several embodiments 
of the invention are discussed below. 

[0009] As a method for accessing data contained in a data network system, one 
embodiment of the invention includes the acts of: sending a request to a server 
hosting the data to retrieve the data by activating a key of a mobile device, the 
request being sent by executing a first set of program instructions in the mobile 
device, wherein the mobile device has a display screen and is in communication 
over a wireless data network with the server, and further, wherein the data is 
associated with the mobile device and is also accessible by a computing device 
executing a second set of program instructions and coupled to the server through a 
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data network; receiving the data from the server via the wireless data network, the 
data presented in a first format interpretabie by the first set of program instructions; 
and displaying the data on the display screen of the mobile device. 

[0010] As a computer readable medium Including at least computer program 
code, executable in a mobile device having a display screen, for accessing data 
contained In a data network system, one embodiment of the invention includes at 
least: computer program code for sending a request over a wireless data network to 
a server hosting the data, the data being associated with the mobile device and 
accessible by a computing device coupled to the server through a data network; 
computer program code for receiving the data from the server via the wireless data 
network, the data received presented in a first format displayable by the mobile 
device and presented in a second format when accessed by the computing device; 
and computer program code for displaying the data on the display screen of the 
mobile device. 

[0011] As a computer readable medium including at least computer program 
code executable in a server hosting data, the data accessible by a mobile device 
executing a first browser and by a computing device executing a second browser, 
wherein the mobile device is coupled to the server through a wireless network and 
the computing device is coupled to the server through a data network, one 
embodiment of the invention includes at least: computer program code for receiving 
a request from the mobile device through the wireless network to access the data; 
computer program code for retrieving the data; and computer program code for 
forwarding the data to the mobile device In a first format displayable on the display 
screen of the mobile device. 



UWP1P036C2/1014C2 



4 



09/410,859 



BRIEF DESCRIPTION OF THE DRAWINGS 

[0012] These and other features, aspects, and advantages of the present 
invention will become better understood with regard to the following description, 
appended claims, and accompanying drawings where: 

Figure 1 shows a schematic representation of a data network in which 
the present invention may be practiced; 

Figures 2. a and 2.b illustrate representations of the system architecture 
of the present invention and a layout of a corresponding user account in a 
server in communication with a mobile phone and a PC; 

Figure 3 shows a typical example of a mobile device that houses one 
portion of the linked and compiled processes disclosed in the present invention; 

Figure 4 illustrates a schematic representation of a mutual authentication 
process between a mobile device and a host server to ensure subsequent 
information transacted therebetween is secured; 

Figures 5,a and 5.b are flowchart representations showing the 
corresponding processes in each of the involved deyices; and 

Figures 6, 7, 8, 9 and 10 illustrate examples of personalizing a user 
account being accessed through a self-provisioned rendezvous. 

DETAILED DESCRIPTION OF THE INVENTION 

[0013] In the following detailed description of the present invention, numerous 
specific details are set forth in order to provide a thorough understanding of the 
present invention. However, it will become obvious to those skilled in the art that the 
present invention may be practiced without these specific details. In other instances, 
well known methods, procedures, components, and circuitry have not been 
described in detail to avoid unnecessarily obscuring aspects of the present invention. 

[0014] The following detailed description of the present invention is presented 
largely in temns of procedures, steps, logic blocks, processing, and other symbolic 
representations that resemble the operations of data processing devices coupled to 
networks. These process descriptions and representations are the means used by 
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those experienced or skilled in the art to most effectively convey the substance of 
their work to others skilled in the art. The present invention is a method and system 
for self-provisioning a rendezvous through a thin device to ensure secure access by 
other devices to infomnation in a database in a data network. The method, along with 
the system or architecture to be described in detail below, Is a self-consistent 
sequence of steps leading to a desired result. These steps or processes are those 
requiring physical manipulations of physical quantities. Usually, though not 
necessarily, these quantities may take the fomn of electrical signals capable of being 
stored, transferred, combined, compared, displayed and otherwise manipulated in a 
computer system or electronic computing systems. It proves convenient at times, 
principally for reasons of common usage, to refer to these signals as bits, values, 
elements, symbols, operations, messages, terms, numbers, or the like. It should be 
borne in mind that all of these similar terms are to be associated with the appropriate 
physical quantities and are merely convenient labels applied to these quantities. 
Unless specifically stated otherwise as apparent from the following description, it is 
appreciated that throughout the present description, discussions utilizing terms such 
as "processing," "computing," "verifying," "displaying," or the like, refer to the actions 
and processes of a computing system that manipulates and transfonns data 
represented as physical quantities within the computing device's registers and 
memories into other data similariy represented as physical quantities within the 
computing device or other such device, such as storage, transmission or display 
devices. 

[0015] Referring now to the drawings, in which like numerals refer to like parts 
throughout the several views. Figure 1 shows a schematic representation of a data 
network 100 in which the present invention may be practiced. The data network 100 
comprises an airnet 102 that is generally called a wireless network, and a landnet 
104 that is generally a iandline network, each acting as a communication medium for 
data transmission therethrough. The airnet 102, in which transmission is via the air, 
is sometimes referred to as a carrier network because each airnet is controlled and 
operated by a carrier, for example, AT&T and GTE, each having its own 
communication scheme, such as CDPD. CDMA. GSM and TDMA, for the airnet 102. 
The landnet 104 or the Intemet, used interchangeably herein, may be the Internet, 
an intranet or other private networks. Referenced by 106 is a mobile data device, but 
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resembling a mobile phone therein, in communication with the aimet 102 via an 
antenna 108. It is generally understood that the aimet 102 communicates 
simultaneously with a plurality of mobile computing devices of which only a mobile or 
cellular phone 106 is shown in the figure. Similarly, connected to the Internet 104 are 
a plurality of desktop PCs 110 and a plurality of servers 112, though only one 
representative is shown in the figure. The PC 110, as shown in the figure, may be a 
personal computer and mns a HTML Web browser via the Internet 104 using HTTP 
to access information stored in the web server 112 which may be a workstation. It is 
understood by those skilled in the art that the PC 1 10 can store accessible 
information therein so as to become a web server as well. Between the Internet 104 
and the aimet 102 there is a link server 1 14 performing data communication between 
the Internet 104 and the airnet 102. The link sen/er 1 14, also referred to as a link 
proxy or gateway, may be a workstation or a personal computer and performs 
mapping or translation functions, for example, communication protocol mapping from 
one protocol to another, thereby a mobile device 106 can be in communication with 
any one of the servers 1 1 2 or the PCs 110. 

[0016] The communication protocol in the Internet 104 is the well known 
HyperText Transfer Protocol (HTTP) and runs on TCP and controls the connection of 
a well known HyperText Markup Language Web browser, (HTML Web browser), to a 
Web server and the exchange of information therebetween. The communication 
protocol between the mobile device 106 and the link server 1 14 via the airnet 102 is 
Handheld Device Transport Protocol (HDTP) or Secure Uplink Gateway Protocol 
(SUGP), which preferably run on User Datagram Protocol (UDP) and controls the 
connection of a HDML Web browser to a link server and a set of commands or 
statements that specify how information is displayed. HDML stands for Handheld 
Device Markup Language, which is similar to that of HTML. The specifications of 
both HDTP and HDML, being considered as the wireless network standards, 
areavailable for additional details. Further, a reference specification entitled 
"Magellan SUGP Protocol." a HTTP specification with network security features, is 
incorporated herein by U.S. Patent No. 6,065,120. HDTP is a session-level protocol 
that resembles HTTP but without incurring the overhead thereof and is highly 
optimized for use in mobile devices that have significantly less computing power and 
memory. Further, it is understood by those skilled in the art that the UDP does not 
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require a connection to be established between a client and a server before 
information can be exchanged, which eliminates the need for exchanging a large 
number of packets during a session between a client and a server. Exchanging a 
very small number of packets during a transaction is one of the desired features for a 
mobile device with very limited computing power and memory to effectively interact 
with a landline device. 

[0017] Referring now to Figures 2.a and 2.b, there is depicted a representation 
of the architecture 120 of the present invention. As described above, the aimet 102 
communicates simultaneously with a plurality of two-way mobile communication 
devices, 122, 124 and 126, generally from a group consisting of mobile phones, two- 
way pagers and telephones. Due to the increasing reduction in size and weight and 
high portability, most of the mobile devices, considered as thin clients, have a very 
limited computing power, typically equivalent to less than one percent of what is 
provided in a typical desktop or portable computer. The memory capacity in a thin 
client is generally less than 250 kilobytes and the LCD display thereof is perhaps 
four lines high by twelve or twenty characters, the graphics capabilities thereof are 
very limited or nearly nonexistent and the general user interface is a keypad having 
far less buttons than a PC keyboard. Therefore, many transactions desired by users 
through such clients are preferably predetermined or pre-entered in their user 
accounts in a host server 128. As such, the users need only to select desired 
transactions to perform or at most key in one or two letters corresponding to desired 
entries through the keypads of their cellular phones. For example, if there is a list of 
stock symbols of interest in a user account that is designated to a mobile phone, a 
user of the mobile phone will not have to key in the symbols every time he desires to 
look up the price thereof cunrently being traded in the stock market. The list of stock 
symbols is previously entered to the user account. Evidently the most available and 
convenient means for now is to use a computing device that has powerful and full 
functional information entering capabilities. A PC is a typical example of such 
computing device, the PC can be equipped with the well-known HTML browser that 
provides a rich graphic user interface and an ideal environment for the user to 
manage his personalized information in his account. 

[0018] As is well known, the Internet 104 is typically a landline network 
connecting computers that utilize the HTML browser. Referenced by 1 10 is a PC 
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representing one of the computers that use the HTML browser running on HTTP to 
hyperlink to other connputers/servers 132 or 134 to update/fetch information on line 
or simply copy files therefrom. It should be noted that "user account" and "database" 
have been used herein sometimes interchangeably when only one account is being 
addressed. It is generally understood that a database or an allocation of memory, as 
referenced by 130 in the Figures 2. a and 2.b, hosts a plurality of user accounts, each 
designated to an authorized capacity in which managed or personalized information 
is kept. Further it is understood that the database 130 can be an independent 
storage or physically a part of the host server 128. To access the personalized 
information therein from any computer on the Internet 104, one has to provide an 
account entry, namely a rendezvous, to a user account in the host server 128 or 
database 1 30 with a set of credential information such as a username and a 
password. Figure 2.b illustrates a layout of a typical user account assigned with a 
mobile phone 106. Each mobile phone is assigned to a device ID 140 which can be 
a phone number of the phone or a combination of an IP address and a port number, 
for example: 204.163.165.132:01905; where 204.163.165.132 is the IP address, and 
01905 is the port number. The device ID 140 is further associated with a subscriber 
number 142 authorized by a carrier in the link server 1 14 as part of the procedures to 
activate the phone 106. The subscriber number may take the form, for example, of 
861234567-10900_pn.mobile.att,net by AT&T Wireless Service, it is a unique 
identification to the phone 106. In other words, each of the mobile devices 122. 124 
and 126 of Figure 2. a has a unique device ID that corresponds to a user account in a 
server. It may be appreciated by those skilled in the art that the link server 114 does 
not have to be a separate server to perform the communication protocol mapping, it 
can be a part of the host server 128 and the protocol mapping is part of the functions 
the host server 128 provides. 

[0019] A corresponding account 144 in the database 1 30 is indexed by an 
account structure 143 comprising subscriber number 142, user information 146, a 
username 148 and a password 150. Subscriber number 142 is received from the link 
server 1 14 as an index to the account structure 143. The user infomnation 146 
comprises the account configuration and other account related infonmation. The 
username 148 and the password 150, namely, the user credential information, 
control the authentication to enter the account 144 in the database 130. From the 



UWP1P036C2/1014C2 



9 



09/410,859 



data network perspective, any computer can logon through HTTP to the rendezvous 
152 identified by an address identifier, often a universal resource locator (URL) 
taking the form of vmw.xyz.com. In other words, each account in a database is 
exclusively associated with a rendezvous identified by a unique URL. As shown in 
the figure, the PC 110 establishes a communication session with the rendezvous 
152 based on a given URL of the rendezvous 152. However, to access the 
associated account 144 in the database 130, the PC 1 10 must provide a set of a 
correct username and password to the rendezvous 152 that performs a verification 
thereof with the account stmcture 143. If the supplied username and password 
match those in the account stmcture 143, the access requested by the PC 1 10 is 
allowed. Otherwise, entry to the account 144 is denied, 

[0020] The PC 1 10 can update information stored in the account 144 when the 
supplied username and password are verified. Using the powerful and familiar HTML 
browser in the PC 1 10, a user can key in frequently requested information, such as a 
list of stock symbols and a list of URLs of Web servers that provide sen/ices to the 
phone 106. All the information entered through the PC 110 becomes immediately 
available to the phone 106. 

[0021] A process named webpwd.cpp in the code listing in the appended 
Microfiche Appendix A illustrates a provisioning process between the phone 106 and 
the link server 1 14 in one embodiment of the present invention. Upon the request of 
the phone 106, the process, specifically in a subprocess called 
setNameAndPasswordStateO, allows the phone 106 to supply a username and a 
password and then send the newly supplied credential information to a second 
subprocess called submitState() that checks if the entered username and password 
are acceptable, namely the username and password should have a certain length 
and contain no spaces or unrecognized characters with respect to a general rule of 
being a usemame and password. If the username and password are not acceptable, 
the subprocess submitStateQ returns to the phone 106 with a con-esponding 
message being either •'You must enter a name" or "You must enter a password." 
Otherwise, the newly entered username and password are sent to another 
subprocess called SetUserAuth{) In a process called HTTPDBMSUserDB. The 
subprocess SetUserAuth{) updates the usemame and password in the account 
stmcture 143. which immediately requires all subsequent logins to the rendezvous 
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152 with the newly supplied usemame and password. A subprocess Authenticate() 
examines a set of a usemame and password supplied by the PC 1 10 and compares 
the usemame and password from the PC 110 to the ones in the account structure 
143. If the comparison is successful, the subprocess AuthenticateQ returns a 
AuthPass flag that allows the PC 1 10 to access the account in the database. 
Otherwise, it returns a flag that denies the admission of the PC 110 to the account. 

[0022] It should be noted that the communication between the phone 106 and 
the link server 114 is through the airnet 102 as shown in Figures 1 and 2.a. 
Messages carrying proprietary information travelling in the air are not secure. To 
transact credential information over the open space to provision the rendezvous, a 
user must have an efficient, reliable and secured manner to conduct private 
communications with the link server. According to one embodiment of the present 
invention, an authenticated and secure session between the cellular phone 106 and 
the link server 114 must be in place before the cellular phone provisions the 
rendezvous through which the user accesses his/her account from other computers. 
It is necessary to refer to an architecture of a mobile phone before proceeding with 
the detailed description of creating the authenticated and secure communication 
between a user's phone (client) and a server. Figure 3 is a block diagram of a typical 
GSM digital cellular phone 160. Each of the hardware components In the cellular 
phone 160 is known to those skilled in the art and so the hardware components are 
not described in detail herein. Although the user Interface of the phone 160 is not 
shown in detail in the figure, the phone 160 may be the mobile device 1 18 of Figure 
1 , having a LCD screen 116 and a key pad 118. The screen 116 prompts a user to 
proceed with the keypad 1 18 with a sequence of key entries, and through the phone 
160, a user can interactively communicate with a server through the airnet, link 
server and the Intemet. According to one embodiment of the present Invention, 
compiled and linked processes of the present invention are stored In ROM 162 as a 
client module 164 and support module 166. Upon activation of a predetermined key 
sequence utilizing the keypad 118, a physical layer processor or microcontroller 610 
initiates a session communication to the server using the module 164 in the ROM 
162. 

[0023] To establish a secured communication between a cellular phone (a 
client) and a server, an authentication process must be conducted first to ensure that 
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only interested parties are actually In the communication therebetween. According to 
one embodiment of the present invention, the code listing thereof being provided in 
the appended Microfiche Appendix, the process is complete through two rounds of 
independent authentication, one being the client authenticated by the server, 
referred to as client authentication, and the other being the server authenticated by 
the client, referred to as server authentication. Further, each authentication is 
completed in two separate steps for a high grade of security, which will be described 
in detail below. The success of the mutual authentication processes provisions and 
evidences that the two communicating parties possess a valid shared secret encrypt 
key through a mutual decryption and a challenge/response mechanism. The mutual 
decryption mechanism comprises the steps of mutually recovering encrypted 
messages from two involved communicating parties. The challenge/response 
mechanism, referred to as nonce verification, verifies a predetermined relationship 
between a sent nonce and a received derivative thereof. 

[0024] In one preferred embodiment of the present invention, the authentication 
process is conducted with three message exchanges; a Session Request (SR) 174, 
a Session Reply (SP) 176, and a Session Gomplete (SC) 178. Figure 4 illustrates a 
schematic representation of the authentication process. Representing a mobile 
device or the cellular phone 106 of Figure 1 , the client 170 conducts a transaction 
with the server 172, such as the link server 1 14 of Figures 2.a and 2.b, and initiates 
a Session Request 174 to be sent to the sen/er 172 by first creating a client proto- 
session. A client proto-session is a session data structure that is initialized when a 
session creation starts. The initialized Session Request 174 comprises the following 
essential information: 

sessionID - an identifier identifying all requests from the client to the server; in 
the case of requesting a session creation, sessionID is always assigned to 0; 

cipher - a two-byte number representing the choice of the encryption the client 
is currently using as there are a number of encryption schemes available in a 
communication protocol; 

devicelD - a variable up to 255-bytes, representing the device identifier or the 
client identifier, comprising a phone number of the device or an IP address 
and a port number, e.g., 204.163.165.132:01905; 
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C-nonce - a client nonce represented with a non-repeatable number, usually 
2 bytes, used for the client to conduct a following server authentication; and 

C-nonceModifled - a modified version of the client nonce, used for the server 
to conduct a nonce verification in the following client authentication. 

[0025] Further, the cipher in the Session Request 174 includes an identifier to 
an encryption algorithm and associated parameters thereof. To be more specific, the 
first byte in the cipher represents an identifier to a combination of the encryption 
algorithm, the key size (e.g., 128-bit for the U.S. or 40-bit for foreign countries) and 
content of a security attachment thereto; and the second byte in the cipher indicates 
the additional parameters related to the first byte._For example, value 1 in the first 
byte indicates that the encryption algorithm is block cipher RC5. the key size thereof 
is 128 bit, a two byte check-sum therein is used as the MAC (Message 
Authentication Code), no IV (Initialization Vector for block ciphers) therefor is 
transmitted over the network, and padding bytes are added if necessary. The block 
cipher algorithm RC5 is part of the RSA's BSAFE product. It can be further 
appreciated that the identifier in the cipher may be assigned to a unique value to 
identify a non-secure session if so desired. The C-nonce is a non-repeatable number 
initially and randomly generated in the client and the modified version thereof; C- 
nonceModified is generated from the C-nonce through an operational relationship. 
For example, the Exc!usive-OR relationship or expressed as follows: 

C-nonceModified = 2-byte-number © C-nonce. 

[0026] it can be appreciated by those who are skilled in the art that there are 
many ways to get the C-nonceModified from a C-nonce. the Exclusive-OR is one of 
the operational relationships used in one embodiment of the present invention. Both 
C-nonce and C-nonceModified are encrypted using the shared secret encrypt key 
between the client 170 and the server 172. The purpose of the C-nonceModtfled is to 
provide the server that receives the Session Request with means for ensuring that 
C-nonce is correctly decrypted and validated by examining the C-nonce and its 
relationship with the C-nonceModified. Both should not be altered after a successful 
decryption of the C-nonce and the C-nonceModified. In other words, a Session 
Request message or signal may be expressed as follows: 

SR = {session ID. cipher, device ID, Encry[nonce, nonceModified]}; 
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where Encry[ ] means that the parameters or contents in the bracket are encrypted 
accordingly. When the Session Request is sent by the client to the server to request 
a session creation, both C-nonce and C-nonceModified are encrypted according to 
the cipher the client is using at the time the Session Request is sent out. 

[0027] Upon receiving the Session Request from the client 170, the server 172 
creates a server proto-session for the client 170 with a session Identifier, refenred to 
as session ID, to identify the session context for the session just created in the 
server 172. A server proto-session is a session entry marked as a proto status in a 
session table, which Indicates that the session is not authenticated and Is not able to 
conduct any transactions with the client. It Is understood to those skilled In the art 
that the proto-session can be kept in the RAM of the server. If a proto-session 
already exists for that client, it is re-used. The information in the received Session 
Request is saved in the server proto-session. If the sen/er 1 72 is satisfied with the 
fact that the client is known, namely Encry[C-nonce. C-nonceModified] in the 
received Session Request are successfully decrypted with the shared secret encrypt 
key, step one in the client authentication process is successful and a corresponding 
session key is generated and stored with the server proto-session entry. It may be 
noted herein that many encryption schemes used in this invention, such as the 
scheme utilizing RC5, have a procedure that adds and validates the Message 
Authentication Code, such as the check-sum, to assure that the encrypted message 
is con*ectly decrypted. The procedure, every time the decryption takes place, is used 
herein to examine the transaction Integrity, namely to ensure the received messages 
or signals are unaltered in the cause of data transmission. If step one in the client 
authentication is not successful, namely, if Encry[C-nonce, C-nonceModified] in the 
received Session Request are not fully decrypted or supported, the proto-session is 
aborted and removed from the proto session table, resulting in a failed session 
creation. What the support means herein is the cipher proposed or used by the client 
is also used by the server, for example, the client uses the RC5 encryption to encrypt 
Encry[C-nonce, C-nonceModified]; to decrypt Encry[C-nonce, C-nonceModified], the 
server must be equipped with the same RC5 encryption capability therein. If 
EncrytC-nonce, C-nonceModlfied] can not be successfully decrypted due to other 
reasons such as transmission errors, the client must reinitiate a new session request 
to the server in order to establish a secure communication with the server. To 



UWP1P036C2/1014C2 



14 



09/410,859 



challenge step two of server authentication subsequently at the client side, a 
derivative of the client nonce or C-nonce is generated therefor. In one embodiment 
of the present invention, the derivative Is created by adding a constant to the client 
nonce, for example, derivative = C-nonce + 1 . The purpose of the derivative is to 
provide the client with means for reassuring that the C-nonce is con-ectly decrypted 
by the server and the server is the correct sen/er with which the client should be in 
communication. 

[0028] Right after the successful step one client authentication, the server 172 
responds to the client with a Session Reply (SP) 176 to begin a second round of 
authentication; server authentication. The Session Reply 176 comprises the 
following information: 

C-SID - a one byte number indicates the sessionID originally assigned in the 
client, to be more specific, C-SID = 0 indicates a clear text client session, C- 
SID = 1 indicates a shared secret key encrypted session, and C-SID = 2 
Indicates a session key encrypted session. In the context of the current 
description, C-SID = 1; 

sessionID - a four-byte number representing an identification and parameters, 
such as a session encrypt key, of the session created by the server for the 
client; 

key - a session key to be used with a mutually acceptable encryption, and to 
be used for encryption and decryption in all transactions in the session; 

derivative - a number derived from the C-nonce for the client to perform the 
subsequent server authentication; 

S-nonce - a non-repeatable number, used for the server to conduct a 
following step-two client authentication; it should be noted that S-nonce is 
generated by the server and generally different from the C-nonce by the 
client; and 

cipher - a two-byte number representing the choice of the encryption the 
server proposes after the client proposed cipher is received. It may or may not 
be the same as the one used in the client. To be more specific, the cipher is 
the same as the one proposed by the client when the server supports the 
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client proposed cipher, otherwise the cipher is the one currently used in the 
server. 

[0029] In other words, the Session Reply can be expressed as follows. 

SP={C-SID, Encry[sessionlD. key, S-nonce, derivative, cipher]} 

When the client 170 receives the Session Reply 176 from the server 172, it perfomns 
the step one server authentication, which is considered successful if 
Encry[sess!onlD. key, S-nonce, derivative, cipher] in the received Session Reply 176 
is decrypted successfully with the shared encrypt key. If the_step one server 
authentication fails, the client 170 discards the Session Reply 176 and a new 
session creation may be started over again. Upon the success of the step one server 
authentication, the client 170 proceeds with the step two server authentication; 
namely, the predetemnined relationship between the C-nonce and the derivative 
thereof should be held for a successful step-two server authentication. 

C-nonce = derivative -1 

[0030] If the C-nonce derived from the Session Reply 1 76 is the same as the C- 
nonce originally generated by the client, the step two server authentication is 
successful; hence, the sen/er 172 is considered authenticated, trusted from the 
viewpoint of the client, and the Session Reply 176 is accepted as a valid message, 
which means that the client 170 then uses the session key and other information in 
the Session Reply 176 for the session being created. Only after completing both 
steps of the server authentication successfully, the client 170 marks the session as 
committed, which means that transactions can be conducted subsequently in the 
session, again only from the viewpoint of the client 170. If the predetemnined 
relationship between the client nonce and the derivative thereof does not hold, the 
step two server authentication fails and the received Session Reply 176 is discarded. 
The client 170 may abort the session creation process if no further Session Replies 
are received and pass both steps of the server authentication process during the 
time period allowed for a session creation. To provide the server with means for 
reassuring the client authentication by itself through the client, a derivative of the S- 
nonce, similar to the derivative of the C-nonce, is generated. 
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[0031] The client 170 then sends the server 172 a Session Complete (SC) 178 
to connpiete the session creation process. The Session Complete 178 comprises the 
following information: 

SC={Encry[derivative]}; 

where the derivative is the client's response to the server nonce challenge, namely 
the result of the verification. The derivative is used by the server 1 72 for step two 
client authentication. Further, it is noted that the Session Complete 178 is an 
encrypted message, meaning that the client encrypts the information in the Session 
Complete 178 according to either its own cipher or the server proposed cipher. 
Generally the client 170 encrypts the information in the Session Complete 178 
according to the server proposed cipher if it accepts the server proposed cipher, 
othenwise, it encrypts the Session Complete according to its own cipher. 

[0032] Upon receipt of the Session Complete 178, the server 1 72 tests if the 
client 170 uses its own proposed cipher or the server proposed cipher by decrypting 
the Session Complete twice using the two ciphers if necessary. If the server 172 
decrypts the encrypted message in the Session Complete 178 and verifies the 
relationship thereof with the S-nonce, the step two client authentication is considered 
successful. Subsequently, the server 172 promotes the server proto-session to the 
active session and the session creation process is completed, thereby an 
authenticated and secure communication session is established between the client 
and the server. Any transactions in the established communications session are now 
encrypted by the session key created in the server according to a cipher mutually 
agreed to by both the client and the server, thereby the transactions between the 
client and the server are truly proprietary. A code listing of one embodiment of the 
mutual authentication is listed in U.S. Patent No. 6.233,608. 

[0033] Referring now to Figures 5.a and 5.b, each illustrates a flowchart 
showing the processes of the present invention in each involved device, respectively, 
in conjunction with Figures 6, 7. 8. 9 and 10 demonstrating examples of 
personalizing a user account being accessed through a self-provisioned rendezvous. 
A client 200, which can be a cellular phone, in Figure 5.a is one of the mobile 
devices communicating with a server 250 in Figure 5.b through a data networi^ 
similar to those illustrated in Figure 1 or Figures 2.a and 2.b. It should be noted that 
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the server 250 functions as a link server and a host sen/er. The functional flowcharts 
on the client and sen/er sides are conjointly described in the following with respect to 
a cellular phone. Nevertheless, it will be appreciated by those skilled in the art that a 
sen/er, without reciting specifically a link server or a host server, as referenced by 
250 can perfonn similar functions, this becomes evident when the client is a landline 
device having direct communication to the Internet. 

[0034] As part of the procedures to activate a cellular phone, a user account, or 
sometimes called a device account, is created in the server 250, the account is 
exclusively associated with the phone or client 200. In other words, each mobile 
device in the data network has its own account identified by a corresponding device 
ID and subsequently a subscriber number in the server 250. The account for the 
client 200 is therefore created and configured at 252 according to services 
subscribed by the client 200. Meanwhile a corresponding account structure, similar 
to 143 in Figure 2.b, is initiated at 254. With an established account in the server 
250. the client 200 becomes one of the clients capable of communicating with any 
computers in a data network. 

[0035] When a user desires to update his personalized information in his 
account, he needs to first self-provision the rendezvous associated with his account 
using the client 200. As is shown in Figure 5.a, the phone therefore requests a 
communication session to the server 250 at 202 for subsequent transactions to take 
place in an authenticated and secure communication session. From the session 
creation described above, it can be appreciated that the session creation requested 
by the client 200 includes a piece of device information assigned to the client 200. 
The device information is sent 204 to the host where a determination is made 206 
whether the device information is recognized. If the device information is not 
recognized by the contacting host 250, no communication session can be possibly 
established therefor. 

[0036] Meanwhile, as shown in Figure 5.b, the host 250 receives the session 
request 258 from the client 200 as part of the session creation process. The device 
information is received at 260 and the session creation process proceeds when the 
device information is verified at 262, which means that the device 200 has an 
authorized account therein. At 208 and 264 a mutual authentication process between 
the client 200 and server 250 takes place. As described above, the mutual 
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authentication process comprises a client authentication and a server authentication, 
each further comprising two steps to ensure that the communicating party is 
authenticated. Resulting from the mutual authentication process or once the session 
Is created and established at 21 0 and 266 of the client 200 and the server 250, 
respectively, a set of session credential information is generated. The session 
credential infomnation comprises a session ID, a session key and a session cipher. 
The session ID Is used to distinguish the session from other sessions that the host is 
creating or has already established with other mobile devices or clients, and the 
session key and the session cipher are to encrypt transactions between the client 
200 and the server 250. At 212, the client 200 has acknowledged that there is a 
rendezvous associated with the account designated to the client 200. If the user 
desires to update his personalized information in the account created and authorized 
in the server 250, he may proceed at 214 with the rendezvous that is generally 
identified by a URL provided by the host 250 and is subsequently prompted for a set 
of user credential information, such as a usemame and a password. At 216, the user 
credential information is entered. The credential information is then sent to the sen/er 
250 at 218, which includes a process of ensuring the newly supplied username and 
password satisfy a general rule of being a usemame and a password. The 
username/password ensuring process has been discussed above and the code 
listing thereof is in U.S. Patent No. 6,233,608. 

[0037] Meanwhile, as is shown in Figure 5.b, the host 250 has acknowledged 
that the client 200 is about to receive a set of new user credential information and 
expects it therefrom at 268. As soon as the new user credential information has 
arrived, the server 250 updates the user credential Information associated with the 
rendezvous at 270. !n other words, to pass through the rendezvous to the user 
account now by other devices, the new credential information must be provided. 

[0038] With the newly updated user credential information, the user can now log 
onto the rendezvous from any computer in the data network. A PC connected to the 
data network (not shown). Is equipped with a familiar HTML-based browser. As an 
example, it is assumed that a user has just provisioned a rendezvous with a 
usemame being "marylee" and the corresponding password being "123456". The 
user now goes to a networi^ed PC that ains a browser and logs onto the rendezvous 
based on the URL of the rendezvous. Figure 6 shows an interactive web page 300 
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received from the server after the PC makes the connection to the rendezvous. It is 
understood to those skilled in the art that the page and subsequent pages can be 
constnjcted with HTML along with CGI script/Java applets, where the process, "CGI" 
stands for Common Gateway Interface, to receive infomnation entered from a user. 
To update his personalized information in his account, the user must provide the 
newly created usemame and password required at 302 and 304, respectively. It 
should be noted that the password entered is generally not echoed at 304 and 
instead indicated with an asterisk con^esponding to each letter entered. When the 
login icon 306 is activated, the entered username and password are retrieved and 
sent, through the network, to the server in which the entered username and 
password are verified; namely, the entered username and password match those 
entered and authorized by the user through the client. The user is then prompted 
with a second web page 310, shown in Figure 7, in which the username is displayed 
as referenced by 312. To categorize personalized information in the account, the 
web page 310 comprises entries to other specific service pages, such as a Personal 
Organizer 314, Bookmari^s 316 and Create Message 318. All these pages are 
accessible by the user to personalize his desired information therein. Figure 8, for 
example, is a page 326 of the Personal Organizer 314 showing a personalized 
address book 320 that allows the user to edit his frequently contacted people's 
phone numbers and other information. Figure 9 is a page 328 of the Bookmarks 316 
showing personalized bookmarks 321 that allows the user to establish a list of web 
sites he may frequently visit through his cellular client. For example, StockTIPS 
rofororjQQrj Ky 322 sllcws ths usef tc k89p 2 list of stock symbols there, \A/ith the 
personalized bookmarks, the user, when on the go, can quickly enter into the web 
pages in his list related to stock to find the prices thereof cun-ently being traded in the 
stock market without keying in any symbols at all. As a convenient feature, a page 
330 in Figure 10 allows the user to create an email message and be replied to at a 
different address 332 as decided by the user, which eliminates the inconvenience of 
typing a lengthy message through a phone keypad and reading a replied message at 
the small screen in the client. 

[0039] The contents in the exemplary pages shown in Figures 6, 7, 8, 9 and 10 
composed by HTML are accessible by an HDML browser through a server providing 
communication protocol mapping and markup language translation functions. 
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Similariy, information or messages entered on the client composed by HDML are 
equally accessible by any computer equipped with an HTML browser through the 
same server in the data network. The duality of the information updating through two 
different mark-up languages provides a useful means for efficiently managing a 
personal account and substantially solves the problems of inconvenient data entry 
through a less functional keypad. 

[0040] The present invention has been described in sufficient detail with a 
certain degree of particularity. It is understood to those skilled in the art that the 
present disclosure of embodiments has been made by way of example only and that 
numerous changes in the arrangement and combination of parts as well as steps 
may be resorted without departing from the spirit and scope of the invention as 
claimed. For example, any mobile devices equipped with a micro browser, e.g., 
HDML browser, may be connected, using an adapter, to the Internet directly without 
going through the aimet. The emerging Intemet-enabled electronic appliances are 
also Internet-connected, all have limited computing powers and keypads but are 
capable of communicating with a server in a data network. The mutual authentication 
between such devices and the server thus becomes less complicated. The mutual 
authentication needs a process of having the client, such as a controller of the 
electronic appliance, authenticated by the server and having the server 
authenticated by the client. The process can be carried out in existing encryption 
mechanisms in HTTPS (an extended version of HTTP with built-in security), in which 
case, the link server could be replaced by a built-in capability in the device, or the 
HTTPS or the transceiver or somewhere in the connection to the Internet. The 
principles of the present invention may still be practiced in such configuration. 
Accordingly, the scope of the present invention is defined by the appended claims 
rather than the foregoing description of one embodiment. 
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